The discussion below is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter. When a user logs in to a computer, a user session is created. In that user session applications are being used. Each application includes one or more processes running in the user session. In order to provide a secure and robust environment to the user, each process should be controlled by applying certain security constraints. These constraints can be applied on different levels, such as a process level establishing e.g. whether the process is allowed to run and/or whether the rights assigned to the process is to be elevated, a file level establishing e.g. whether files are allowed to be read or written by a process, a registry level establishing e.g. whether registry settings are allowed to be read or written by a process, or a network level establishing e.g. whether data is allowed to be sent and/or received to/from the network.
Whether and how processes within a user session should be controlled is provided in rules. Controlling the processes is done via filter drivers implemented in the kernel mode of the computer and a rule provider implemented in the user mode, schematically shown in FIG. 1A illustrating a typical computer 100. As shown, the computer 100 comprises a user mode 110, a kernel mode 120, and an application programming interface (API) 115 which provides a communication medium between the user mode 110 and the kernel mode 120. The user mode 110 comprises at least one software application 112 that could be run, which, in turn, includes at least one process 114. The user mode 110 also comprises a rule provider 116 storing rules for all of the processes that could, potentially, be running in the user mode 110 of the computer 100. The kernel mode 120 comprises various kernel mode filter drivers, shown as a filter driver (FD) 122, a FD 124, and a FD 126, designed to control access of processes to computer resources (e.g. a computer resource could be a network interface card and the process could be a process within a web browser application that needs network access).
Typically, the process 114 is controlled in a manner illustrated in FIGS. 1B and 1C. Such control includes the rule provider 116 providing all possible rules (i.e., all of the rules associated with each of the processes which may possibly be run on the computer 100) to the various kernel mode filter drivers as the user session is being started and/or as the computer is being turned on. This is shown in FIG. 1B with arrows 132, 134, and 136, where the arrow 132 illustrates all rules relevant to the FD 122 being provided to the FD 122, the arrow 134 illustrates all rules relevant to the FD 124 being provided to the FD 124, and the arrow 136 illustrates all rules relevant to the FD 126 being provided to the FD 126. When a filter driver intercepts a request to execute a particular process indicating launching of the process, the driver goes through all of the rules stored therein to determine how the request should be handled, i.e. whether the process should be allowed to run, should be elevated, should be blocked, etc. A filter driver intercepting such a request (arrow 138) from the process 114 to the filter driver 124 is illustrated in FIG. 1C. In such an example, the filter driver 124 goes through all of the rules provided to it from the rule provider 116 in order to make a decision as to how the process 114 should be handled. Once the decision is made, the filter driver 124 provides an indication to the process 114 regarding whether and/or how the process 114 is allowed to continue (this step is not shown in FIGS. 1B-1C).
One problem with the implementation illustrated in FIGS. 1B-1C arises when a computer includes a large number of processes which may be run, where each application is associated with a large number of rules. In such a situation, providing all of these rules to the filter drivers results in the long start up time and large claim on the scarce kernel resources. Another problem is that the filter drivers having to search through the large number of rules stored therein to find the rules applicable to a particular process being launched also results in slow processing of rules in runtime.